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(54) Method and receiver for improved data packet transfer in a transmission protocol with repeat 
requests 



(57) In a method for the transmission of data pack- 
ets (D) from a transmitter (TR) to a receiver (RE), de- 
fective data packets (D) are detected and a first status 
message (S, ) comprising an indication of defective data 
packets is sent from the receiver (RE) to the transmitter 
(TR). A retransmission of defective data packets is per- 
formed according to the first status message ($,). The 
receiver (RE) initializes a timing unit according to the 
sending of the first status message (S, ) and determines 



later that a further status message (S 2 ) indicating defec- 
tive data packets is required. Then, defective data pack- 
ets are selected for the further status message (S 2 ). A 
defective data packet is selected if it is not indicated in 
the first status message (S,) or if the timing unit has 
reached a threshold. Only the indications of the selected 
data packets are included in the further status message 
(S 2 ) and the receiver sends the further status message 
(S z ). A receiver and software programs embodying the 
invention are also described. 
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Description 

Technical field of the invention 

[0001] The present invention relates to a method ac- 
cording to the preamble of claim 1 . A receiver and soft- 
ware programs embodying the invention are also de- 
scribed. 

Background of the invention 

[0002] Different modes can be used for the transmis- 
sion of data packets from a transmitter to a receiver, e. 
g. a transparent mode, an unacknowledged mode or an 
acknowledged mode. By using an ARQ (Automatic Re- 
peat Request) mechanism, the acknowledged mode 
provides the possibility to retransmit data packets which 
are defective, either because they are lost or because 
they have been received in error. In this way, a loss free 
data transmission can be ensured for higher layers in a 
protocol stack although individual data packets of the 
ARQ layer are defective, e.g. due to a disturbed radio 
I ink. To allow an ARQ mechanism it is customary to iden- 
tify the data packets by a sequence number which is 
generally attributed to the packets on a modulo basis. 
Messages from the receiver to the transmitter indicate 
which packets are defective and retransmissions of said 
packets are performed according to the messages. In 
addition, the messages can also acknowledge correctly 
received data packets. 

[0003] The status of transmitted and received data 
packets can be controlled using receiver and transmis- 
sion windows in the receiver and the transmitter, respec- 
tively, i.e. memories which store whether a data packet 
is acknowledged or not. The receiver window according 
to the definition used throughout this text ranges from 
the first unacknowledged packet to the packet with the 
highest received sequence number, generally under 
consideration of a modulo sequence numbering. In an- 
other customary definition which is used e.g. in 3GPP 
(3 rd Generation Partnership Project) specifications, the 
term "receiver window" comprises also a range of se- 
quence numbers above the highest received sequence 
number. This range is not Included in the present defi- 

[0004] An example of a transmission protocol which 
has an acknowledged mode is the RLC (radio link con- 
trol) protocol as described in the 3GPP technical spec- 
ification 3G TS 25.322 V4.0.0 (2001-03) of the 3 rd Gen- 
eration Partnership Project, Technical Specification 
Group Radio Access Network. The RLC protocol is used 
for the transmission of data In a WCDMA (Wideband 
Code Division Multiple Access) system, for example in 
the Universal Mobile Telecommunication System 
(UMTS). 

[0005] I n a communication system, the transmitter is 
for example a user equipment like a mobile phone or a 
network node like an RNC (Radio Network Controller). 



The RLC protocol layer in the transmitter receives pack- 
ets, e.g. from a higher layer in the protocol stack. The 
packets from the higher layer are denoted as SDUs 
(Service Data Units). The RLC layer transforms the 

5 SDUs to data packets denoted as packet data units 
(PDU) to prepare them for transmission over a link be- 
tween the transmitter and the receiver. In the RLC layer 
of the transmitter, packet transformations comprise for 
example a segmentation, concatenation or buffering of 

10 SDUs while PDUs can for example be padded or buff- 
ered. The receiver is usually a network node or a user 
equipment communicating with the transmitter. The 
RLC layer of the receiver performs an inverse process- 
ing to release the data either to a higher protocol layer 

« or to forward it to a link layer for transmission through 
further domains of the communication system, for ex- 
ample through a core network of the communication 
system. 

[0006] I n the RLC protocol , the messages indicating 

20 defective data packets are denoted as status reports 
and may consist of one or several protocol data units. 
The RLC specification requires that a status report shall 
include Information about all protocol data units that 
have been received and all units detected as defective. 

25 Accordingly the receiver is reporting at the time when a 
status report is generated about alt protocol data units 
which are currently in the receiver window. To Improve 
the protocol performance in terms of delay and through- 
put optimization It is necessary that retransmissions of 

so erroneously received radio link control protocol data 
units are sent as soon as possible. However, fast re- 
transmissions may result in several retransmissions of 
the same PDU which Is a waste of resources. Several 
status reports within one radio link control (RLC) round 

35 trip time trigger each the retransmission of a particular 
defective protocol data unit because all negatively ac- 
knowledged protocol data units are retransmitted when 
the transmitter receives a status report Especially if sta- 
tus reports are sent as often as possible this may speed 

*o up the protocol but triggers unnecessary retransmis- 
sions. 

[0007] The RLC protocol allows to control the amount 
of status reports by a Status Prohibit Timer. This timer 
prohibits the sending of status reports for a certain 

45 amount of time. If the Status Prohibit Timer is set higher 
than the RLC round trip time, unnecessary retransmis- 
sions are prevented. The disadvantage is that this slows 
down the retransmission of erroneous data packets sig- 
nificantly and results in a slow protocol, especially for a 

so high proportion of defective packets and high round trip 
times. An alternative to avoid unnecessary retransmis- 
sions is the estimated PDU counter (EPC) as described 
in 3GPP specification 3G TS 25.322. The EPC mecha- 
nism comprises both a timer to consider the round trip 

55 time and in addition a counter corresponding to the 
number of packets requested for retransmission. The 
counter eliminates the influence of the link capacity on 
the transmission time but the EPC mechanism also 



2 



3 



EP1 263 159A1 



4 



does not solve the problem that the protocol is slowed 
down by the timer. 

[0008] As a result, current protocols comprising a re- 
transmission of data packets provide basically two op- 
tions which either waste resources or slow down the pro- 
tocol. Neither option provides an optimal performance. 
[0009] Besides these problems, the existing technol- 
ogy can also disadvantageous^/ affect the transport lay- 
er above the ARQ layer, in particular TCP (Transmission 
Control Protocol). TCP is a higher layer protocol which 
is widely used to provide a reliable data transfer in com- 
munication networks, for example In the Internet. Inter- 
active transport protocols like TCP control transmis- 
sions according to reply messages from the receiving to 
the transmitting entity. Control procedures can adapt the 
transmitted data rate according to the replies, e.g. if a 
time-out for a reply indicates a packet loss. A radio link 
control protocol which is contributing to a large transport 
layer round trip time is therefore not only disadvanta- 
geous in itself. The high delay can furthermore trigger 
control procedures of the transport layer, even if a time- 
out results from a radio link round trip time and not from 
a packet loss In the network. As a result the existing RLC 
protocol is often too slow to support high TCP through- 
puts although the underlying physical layer would allow 
a corresponding data rate. 

[0010] Finally, a large round trip time can cause a 
Stalling condition of the transmission window in case of 
a limited window size, e.g. if a modulo sequence num- 
bering Is used. In a stalled window ail positions are at- 
tributed to data packets. The window can not be shifted 
and new data packets accordingly not be sent until the 
oldest defective data packet is acknowledged. This 
blocks the data transmission. 

Summary and description of the invention 

[0011] It is an object of the present invention to obvi- 
ate the above disadvantages and provide a method and 
a receiver for an improved transmission of data packets 
in a communication system. It Is especially an object to 
avoid unnecessary multiple transmissions and ensure a 
low transmission delay. 

[0012] According to the invention, the method de- 
scribed in claim 1 is performed. Furthermore, the inven- 
tion is embodied in a receiver and a program unit as de- 
scribed in claims 16 and 19. Advantageous embodi- 
ments are described in the further claims. 
[0013] In the proposed method for the transmission of 
data packets from a transmitter to a receiver, defective 
data packets are detected in the receiver and a first sta- 
tus message with an indication of defective data packets 
is sent from the receiver to the transmitter. A defective 
data packet can be a data packet in which an error is 
detected, e.g. by checking control information in the da- 
ta packet like a check sum, or which is detected as miss- 
ing, e.g. when the corresponding sequence number is 
not received. A retransmission of data packets indicated 



as defective is performed by the transmitter according 
to the first status message. 

P»014| A basic idea of the invention is that the receiver 
does not report about all defective data packets each 

s time it sends a status message. For this purpose the 
receiver initializes a timing unit according to the time 
when the first status message is sent and a threshold 
corresponds to said status message. For example, a 
first timer or a counter can be started when the status 

io message is forwarded fortransmission to an underlying 
layer in the protocol stack or when the transmission is 
started by a physical layer. The timing unit preferably 
reaches the threshold after one round trip time, which 
can for example be represented by a pre-configured 

15 constant value of a counter or timer or by a measured 
round trip time between the transmitter and the receiver. 
A setting of the threshold corresponding to a slightly 
higher vaiue than one round trip time can allow for var- 
iations and increases the stability of the proposed meth- 

20 od. 

[0015] After the timing unit is started the receiver de- 
termines that a further status message indicating defec- 
tive data packets is required. For example, the receiver 
will generally receive further data packets which are also 

25 checked for defects and the further status message can 
be triggered when a predefined number of further de- 
fective data packets is detected. The receiver can also 
determine independently of data packets detected as 
defective that a further status message is required, e.g. 

30 when a request for a status message is received from 
the transmitter or when the timing unit or another timer 
reaches a defined threshold. 
[001 6] Data packets identified as defective are select- 
ed for indication in the further status message. Indica- 

35 tions of the defective data packets are not included in 
the further status message if a check indicates that the 
defective data packet is Indicated In a preceding status 
message, especially in the first status message, and if 
the timing unit has not reached the corresponding 

<o threshold, e.g. if a timer is not expired. It is possible that 
the threshold is determined during these checks while 
determining it already at the sending of the data packet 
Is not required for all embodiments of the method . In an- 
other option, the further status message is triggered 

45 when the timing unit reaches the threshold or a defined 
fraction of it. In this case, the check whethera data pack- 
et is indicated In the first status message can be simpli- 
fied to the selection of defective data packets from one 
or several specified parts of a receiver window. 

50 [0017] In case of a negative result for one condition, 
the respective other condition for the selection of a de- 
fective data packet needs not to be checked. For exam- 
ple after the threshold is reached a packet can be in- 
cluded in the further status message without a check 

55 whether it is indicated in the corresponding status mes- 
sage. According to the sending of the further status mes- 
sage a further threshold can be defined, e.g. as a pre- 
configured constant or a measured value as described 



3 



5 



EP12631S9A1 



6 



above. The further threshold is evaluated in the same 
way as the first threshold for still further status messag- 
es in comparison to the same or a further timing unit. 
[001 8] The further status message can be sent before 
the threshold is reached to speed up retransmissions, s 
A further request for the retransmission of already re- 
quested data packets is delayed according to the 
threshold which represents the expected arrival of the 
already requested retransmissions at the receiver. Still 
further status reports can be sent before the first and w 
further thresholds are reached but in any status report 
only those defective data packets are indicated which 
were either not indicated in any former status message 
or for which the corresponding threshold Is reached or 
passed. is 
[0019] The invention can for example be implemented 
in a user equipment in orderto speed up downlink traffic 
to the user. It is also advantageous to implement the in- 
vention in a network node adapted to set up connections 
with user equipment, e.g. in a radio network controller 20 
RNC or in a radio base station depending on the node 
in which the protocol controlling transmissions over the 
link is terminated. Preferably the proposed method is im- 
plemented at both ends of the link because generally 
both sides can be the receiver. It is however also pos- 25 
slble to Implement the method only in one receiver, es- 
pecially on the side of the link to which most data traffic 
Is sent which is typically the downlink side. It is espe- 
cially advantageous that adaptations of the transmitter 
are not required. 30 
[0020] The invention speeds up the radio link control 
protocol by allowing an early retransmission of defective 
packets while avoiding retransmissions which are not 
necessary. An early retransmission has the advantage 
that the data traffic is less bursty, i.e. the variations in 35 
the intervals between data delivery to higher layers are 
red uced, especially in case of an in-order delivery of da- 
ta packets by the proposed protocol to the higher layer. 
The processing requirements for all devices in a con- 
nection can be decreased in this way. The proposed *> 
method is especially beneficial for TCP traffic and re- 
duces the probability of a stalling transmission window 
significantly. 

[0021] In a preferred embodiment of the invention, the 
timing unit is a timer and the threshold is the expiry of « 
the timer. It is possible to use a different timer for every 
status message and set the expiry value to the round 
trip time. It is also an option to use a single timer for all 
status messages and set the expiry threshold to the tim- 
er value at the sending of the status message plus the so 
expected round trip time. The use of timers allows a very 
precise implementation of the proposed method. 
[0022] To limit the number of timers required for the 
method, an advantageous timer comprises a threshold 
timer with a threshold set to an expiry value. In addition, 55 
the timing unit comprises an interval timer. The thresh- 
old timer and the interval timer are started according to 
the sending of the first status message. When a subse- 



quent status message is sent, the value of the interval 
timer is stored and the interval timer is reset and restart- 
ed. The threshold timer is reset and restarted when it 
reaches the expiry threshold and the expiry threshold is 
set to the stored value of the interval timer. The proce- 
dure can be repeated for any subsequent status mes- 
sage. In this way, any number of status messages can 
be tracked with a single timing unit 
[0023] In an alternative embodiment, the timing unit 
comprises a packet counter for received packets and 
the threshold is a counter value. In an option, the counter 
is not evaluated directly in the selection of data packets 
but the reaching of the threshold or a defined fraction of 
the threshold by the timing unit triggers the further status 
message. The selection of the requested data packets 
for the further status message can in this case be all 
defective packets from one or more intervals defined 
with respect to the present value of a transmission var- 
iable, especially the sequence number of the upper bor- 
der of a receiver window, and the threshold value. This 
allows a very simple implementation of the invention and 
is suitable especially for constant data rates while a var- 
ying date rate can cause erroneous estimates of the 
round trip time. For a small number or magnitude of er- 
roneous estimates, the total amount of unnecessary re- 
transmissions is still significantly reduced. 
[0024] Stfll further status messages can be sent and 
a corresponding number of still further thresholds can 
be determined, i.e. a threshold can also be determined 
for the second status message and at least one third 
status message can be sent An indication of a defective 
data packet is only included in any further status mes- 
sage if said packet is not included in any preceding first 
or further status message or if the corresponding thresh- 
old is reached. In this way, multiple status messages can 
be sent during a round trip time without or with signifi- 
cantly reduced risk of unnecessary retransmissions. 
[0025] The receiver can determine that a status mes- 
sage is required by using any single condition described 
In the following or any combination of such conditions. 
For example, the receiver can determine that a status 
message is required when it receives a polling request 
from the transmitter. A status message can also be trig- 
gered after a predefined number of data packets is re- 
ceived or after each data packet being detected as de- 
fective or after a predefined number of defective data 
packets. Status messages can also be sent in regular 
intervals, e.g. measured in milliseconds or transmission 
time intervals (TTI), orafterthe threshold ordefined frac- 
tion of the threshold is reached by the timing unit, i.e. 
after expiry of a status timer or a counter. The latter op- 
tion is especially advantageous because it simplifies the 
selection of defective data packets for further status 
messages. It is also possible to use a combination of a 
timer and a packet counter as in the EPC method. To 
avoid that packets of a higher layer in the protocol stack 
are blocked by single missing packets from the ARQ lay- 
er a status message can be sent at the end or beginning 
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of packets from a higher layer of the protocol stack. Still 
further conditions can be the size of the status message 
content, i.e. that the content fits Into one or a predefined 
number of data packets or that a status message indi- 
cates a certain number of data packets. A further ad- s 
vantageous triggering condition is the reception of a pre- 
determined fraction of a receiver window. The selected 
condition or combination can be used to optimize the 
speed of retransmissions, the overhead necessary for 
the status messages, the burstyness of the traffic, the « 
required memory and processing capacity in the devic- 
es or to attain an advantageous compromise of param- 
eters. 

[0026] The time between two subsequent status mes- 
sages, e.g. between the first status message and the « 
further status message, is preferably lower than a round 
trip time between the transmitter and the receiver. With 
increasing number of status messages per round trip 
time the overall transmission delay of the protocol by 
defective data packets Is reduced. 20 
[0027] In many transmission systems data can be 
transmitted over channels with different properties. Es- 
pecially, transmissions of a user in a communication 
system are performed either over a channel dedicated 
to the user or over a shared channel. On a dedicated 25 
channel the user has generally a defined bandwidth and 
delay for transmissions. These parameters can be dif- 
ferent for another dedicated channel and they may vary 
for a shared channel, e.g. according to the behavior of 
other users in the communication system. It Is advanta- 30 
geous that the first threshold or any further threshold is 
determined according to the properties of the channel 
used for data transfer. In this way the retransmissions 
can be performed faster on a channel with low delay. A 
threshold independent of the channel properties is more 35 
simple to configure but can introduce unnecessary de- 
lays. 

[0028] To identify the data packets which are indicat- 
ed in the status messages the receiver preferably has 
a memory to store a corresponding information. For ex- 40 
ample, the receiver can store at least one boundary of 
an interval of sequence numbers, the interval compris- 
ing packets in a first or further status message. The 
memory can alternatively store a status message 
number or a timing unit number or threshold numberfor *e 
each retransmitted data packet. It is also possible to at- 
tribute a timer permanently to a specific range of se- 
quence numbers (e.g. timer n may be attributed to the 
sequence numbers [n*256, n*256+255] with n = 0, 1, 
2, ...). The latter alternative is especially suitable if all so 
ranges of sequence numbers have the same size. It is 
less flexible but easy to configure and does not require 
a memory for storing which data packets are indicated 
in a specific status message. 

[0029] The threshold preferably corresponds to ap- 55 
proximately one round trip time to avoid unnecessary 
retransmissions without slowing down the protocol. If 
the round trip time can vary, a value higher than the av- 



erage round trip time reduces the probability of unnec- 
essary retransmissions while increasing the delay. The 
most preferable option is therefore to set the threshold, 
e.g. the timer expiry, to a value corresponding to a slight- 
ly higher time than one round trip time to allow for vari- 
ations and ensure a high stability of the proposed meth- 
od, i.e. to adapt the threshold by a correction value for 
the round trip time. A suitable magnitude of the correc- 
tion value can depend on different parameters like the 
proportion of retransmissions. Optionally, the timing unit 
comprises both a timer to consider the round trip time 
and a packet counter to determine the correction value. 
[0030] To reduce the number of data packets which 
are in the transmission window of the transmitter, an ad- 
vantageous status message comprises indications of all 
correctly received data packets, e.g. since the last sta- 
tus message or in the receiver window. Because these 
packets are not requested for retransmission, there is 
no risk of multiple transmissions while an early acknowl- 
edgment to the transmitter allows a shifting of the trans- 
mission window to avoid a stalling. 
[0031] The proposed method is especially advanta- 
geous for implementation in an RLC layer of the receiv- 
er, i.e. if the packets are RLC packet data units. 
[0032] It is also advantageous to use the proposed 
method for the data packets of a physical layer In a pro- 
tocol stack. This is especially beneficial for the HSDPA 
(High speed downlink packet access) evolution of WCD- 
MA which uses an ARQ mechanism on the physical lay- 
er of the protocol stack. In HSDPA a hybrid ARQ mech- 
anism can be applied in which erroneous data packets 
are not discarded but Information from different trans- 
missions of the same packet can be combined to recon- 
struct the packet Especially in this case, It Is often ad- 
vantageous if the original and the retransmitted data 
packet are not identical but they may for example be 
coded in a different way to improve the probability of cor- 
rect decoding after combining the original transmission 
and the retransmission. The method can be used both 
for downlink and uplink traffic. On the network side of 
the wireless link, the protocol is preferably implemented 
in a radio base station to speed up the traffic. If the meth- 
od is used on the physical layer this can either be an 
alternative to the application on a higher layer, e.g. RLC, 
or as a backup solution in which the method is used both 
on the physical layer and a higher layer. 
[0033] A receiver for a commu nicatlon system for the 
transmission of data packets according to an ARQ 
mechanism comprises a unit for the detection of defec- 
tive data packets and a communication unit to initiate 
status messages with an indication of defective data 
packets to a transmitter in the communication system. 
According to the invention, the receiver is provided with 
a timing unit and adapted to initializes the timing unit 
according to the initiation of a first status message. For 
example, the receiver can be adapted to start a first tim- 
er according to the initiation of a first status message. A 
control unit determines that a further status message in- 
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dicating defective data packels is required, e.g. accord- 
ing to one of the conditions described with respect to the 
proposed method. 

[0034] The receiver is furthermore provided with a unit 
adapted to perform a check whether a defective data 
packet is included in any preceding status message, es- 
pecially in the first status message, and whether the cor- 
responding timing unit has reached a threshold, e.g. 
whether the first timer is expired. The receiver includes 
the indication of a defective data packet in the further 
status message if the data packet is not indicated in a 
preceding status message or if the corresponding timing 
unit has reached the threshold, e.g. the corresponding 
timer Is expired. The communication unit initiates the 
further status message comprising indications of the se- 
lected data packets. The receiver preferably initializes 
a further timing unit and/or determines a further thresh- 
old according to the initiation of the further status mes- 
sage, e.g. starts a further timer according to the initiation 
of the further status message. The above units can for 
example be implemented as software which is executed 
in a processing system of the receiver. The receiver Is 
preferably adapted to perform one or several of the em- 
bodiments of the method described. 
[0035] The receiver Is for example a radio base sta- 
tion, a user equipment or a radio network controller. The 
same entities can also be a transmitter in the proposed 
method. 

[0036] A program unit according to the invention can 
for example be stored on a data carrier or loadable Into 
a receiver in a communication system, e.g. as a se- 
quence of signals. The program unit can comprise code 
for performing any of the methods described. 
[0037] The foregoing and other objects, features and 
advantages of the present invention will become more 
apparent in the following detailed description of pre- 
ferred embodiments as illustrated in the accompanying 
drawings. 

Brief description of the drawings 
[0038] 

Fig. 1 shows a radio link in a wireless communication 
system in two different representations 

Fig. 2 shows an example of transmitted RLC packets 
during an interval of time 

Fig. 3 shows the handling of data packets according 
to the invention 

Fig. 4 shows a receiver according to the invention 

Detailed description of preferred embodiments of the 
invention 

[0039] Figure 1a illustrates a transmission system 
comprising a wireless link WL. The link WL connects a 
user equipment UE, for example a mobile phone or an- 
other terminal, and a radio network node RN, for exam- 



ple an RNC or a base station. Further equipment nec- 
essary for the connection is omitted for clarity, e.g. in 
case that the node RN is an RNC the wireless link ex- 
tends between the user equipment UE and a radio base 

s station which is in turn connected to the RNC. Both the 
user equipment UE and the node RN can be the trans- 
mitter or the receiver of the present invention, depend- 
ing on the direction in which data packets are sent over 
the wireless link WL. 

10 [0040] User equipment UE and network node RN 
comprise processing systems in which at least parts of 
a protocol stack for the transmission of data is imple- 
mented. The processing stack in the example compris- 
es an application layer AL for executing applications, a 

is transport layer TL, e.g. implementing TCP, a radio link 
control layer RLC and a physical layer PL. Further layers 
which are not depicted can also be present in the pro- 
tocol stack as indicated by dots, e.g. a UMTS system 
comprises a MAC (Medium Access Control) layer be- 

20 tween the RLC and the physical layer PL. 

[0041] The user equipment UE in the example com- 
municates with an application running in a further termi- 
nal equipment TE, for example a server. The application 
layer AL and the transport layer TL are terminated in the 

25 further terminal equipment TE. The data packets be- 
tween user equipment and terminal equipment are sent 
via the node RN and one or more intermediate networks 
NW, e.g. the core network of a communication system. 
Data packets of the transport layer TL are transferred to 

so the RLC layerfortransmission over the wireless link WL. 
The behavior of the RLC packets on the wireless link, 
especially the delays introduced by the properties of the 
RLC layer and all underlying layers, affects the perform- 
ance of the higher layers TL, AL in the protocol stack. 

35 [0042] In figure 1b a model of the communication over 
the wireless link WL is shown from the perspective of 
the RLC layer. The RLC entity RLC,- in the transmitter 
TR sends data packets D, ... D n to the RLC entity RLC R 
in the receiver RE by using underlying layers as de- 

40 scribed above. The receiving entity RLC R acknowledg- 
es the reception of correctly received data packets and 
requests the retransmission of defective data packets 
in a first status message S, which is sent back to the 
transmitter. To speed up the protocol retransmissions of 

« a data packet D are preferably performed with priority 
over those packets which are to be transmitted for the 
first time. 

[0043] The RLC round trip time is the period from the 
sending of the first status message S., , i.e. the forward- 
so ing to the underlying layer in the receiver RE, until the 
reception of the first requested data packet D, i.e. the 
time when this packet is forwarded from the underlying 
layer in the. receiver RE to the RLC entity RLC R . In more 
general terms, the RLC round trip time is the period until 
ss the RLC entity on one end of a link receives a response 
from the RLC entity on the other side. The RLC round 
trip time includes for example propagation delays on the 
link WL as well as processing delays for the transfer of 
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data between different layers In the protocol stacks or 
over interfaces between nodes, e.g. between radio base 
station and RNC. According to the Invention, several fur- 
ther status messages S 2 , S 3 ... can be sent within one 
round trip time while a single retransmission of a re- s 
quested data packet can be ensured within a round trip 
time. 

[0044] Figure 2 depicts a section of an RLC trace for 
a receiver, i.e. the reception of packets indicated by their 
corresponding sequence number over time. Status re- 10 
ports are triggered when a PDU is received in which a 
poll bit is set. The transmitter can set the poll bit for ex- 
ample when the last PDU from a buffer containing new 
or retransmitted PDUs is sent. In the example status re- 
ports are sent in intervals of 50 ms while the RLC round « 
trip time is about 1 00ms. On the link WL between trans- 
mitter and receiver some of the packets are lost or cor- 
rupted as indicated by horizontal bars. The status re- 
ports indicate to the transmitter which packets have to 
be resent. 20 
[0045] In a transmission according to the state of the 
art, e.g. as required by standard 3G TS 25.322, a re- 
transmission is sent for each negative acknowledge- 
ment received by the transmitter. The status report in- 
cludes information about protocol data units that have as 
been received and Information about all PDUs detected 
as defective. If status reports are sent in shorter intervals 
than the radio link control round trip time as in the ex- 
ample, several status reports include the same protocol 
data unit. 30 
[0046] The receiver in figure 2 sends a status report 
to the transmitter every 50 ms. Based on those status 
reports retransmissions are performed. The sequence 
numbers of the retransmitted packets are lowerthan the 
sequence numbers of those packets transmitted forthe 35 
first time which allows to distinguish both kinds of pack- 
ets in figure 2. All erroneously received packets are re- 
transmitted twice because each is included in two status 
reports. For example, the same packets with sequence 
numbers around 950 are retransmitted both at the time « 
41 65 ms and 421 5 ms although the first retransmission 
of the packets was successful. 
[0047] As a resultthere is generally one unnecessary 
retransmission for all negatively acknowledged protocol 
data units in figure 2 unless the first retransmission of a *s 
PDU Is defective. If the interval between status reports 
is increased to avoid unnecessary retransmissions, this 
increases the total transmission delay. Furthermore, es- 
pecially in the case of in-order delivery of data packets 
to higher layers, the traffic tends to be forwarded in so 
bursts if few defective PDUs inhibit the forwarding of the 
data and several SDUs are released in a row when a 
PDU is received correctly after one or several unsuc- 
cessful retransmissions. 

[0048] A method according to the invention Is de- ss 
scribed with respect to figure 3. The horizontal bars in 
the left part of figure 3 represent the receiver window 
RW at different times. The blank parts B, B' of the re- 



ceiver window RW are protected by a corresponding 
timer, i.e. for these parts B, B' of the receiver window a 
status report has been sent and the corresponding timer 
is not expired. The hatched parts are not protected, i.e. 
they can be included In the next status report SR. The 
right part of figure 3 depicts the contents of the status 
reports SR. The following steps start with a first status 
report during a data transmission. Before the first step, 
the receiver has already received PDUs with sequence 
numbers in the interval [x, x + 1 5] which are not acknowl- 
edged so far and upon which the receiver reports in the 
first status report. 

1. The receiver checks whether the PDUs are re- 
ceived without error and sends a first status report 
according to the check. Preferably, the check is per- 
formed immediately afterthe reception of each data 
packet and the result is stored for the status report. 
In the example, the first status report SR comprises 
the status of the protocol data units in the first inter- 
val [x, x+15]. 

2. The receiver stores the sequence numbers of the 
first interval, i.e. the identities of the protocol data 
units which are indicated in the first status report. 
The receiver is preferably provided with a memory 
to store such intervals, e.g. the values of both Inter- 
val boundaries, of one boundary and the interval 
size or only of one boundary if the size of an interval 
is constant. It is also possible that a status report 
contains information about an area of sequence 
numbers which is not contiguous. 

In a still further alternative each timer is attributed 
to a defined section of the receiver window' either 
with respect to a boundary of the window or to ab- 
solute sequence numbers. For this alternative a 
memory for storing the intervals is not required but 
the flexibility Is lower due to predefined sets of 
PDUs protected by the timers. In the latter case any 
interval corresponding to a timer preferably con- 
tains the same number of PDUs. 

3. The receiver starts a first timer for the first inter- 
val. The first timer is preferably set to expire after 
one round trip time between the RLC entities of the 
transmitter and the receiver, measured from the 
time when the first status report is sent. 

4. The receiver receives further protocol data units. 

5. After a predefined condition a second check is 
performed whether data packets are defective and 
a corresponding status report is generated and 
sent The check Is performed only for the unprotect- 
ed parts of the receiver window. Consequently, the 
second status report comprises only indications of 
protocol data units which are not protected by the 
first timer. In the example of figure 3, the receiver 
window at .50 ms comprises protocol data units In 
the range [x,x+25], but the second status report in- 
cludes only protocol data units in the interval 
[x+16,x+25]. 
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6. The receiver stores the sequence numbers of the 
second interval it reported upon. 

7. The receiver starts a second timer for the second 
interval. 

8. The receiver receives retransmissions requested 
by the status report from step 1 . 

9. The first timer expires. If a memory stores the cor- 
responding interval, the interval can be removed 
from the memory or can be marked as unprotected. 

10. The receiver receives additional protocol data 
units. 

1 1 . After a further predefined condition the next sta- 
tus report is generated and sent according to a cor- 
responding check of defective PDUs. The new sta- 
tus report comprises only information about proto- 
col data units, which are not protected by any of the 
timers which are not expired yet. In the example of 
figure 3, the receiver reports about the packets re- 
ceived in step 8 and step 10, i.e. at 100 ms the re- 
ceiver reports about necessary further retransmis- 
sions in the Interval [x,x+1S] and about newly re- 
ceived protocol data units in the interval [x+26, 
x+39]. It does not report about [x+1 6,x+25] because 
this interval is protected by the second timer and 
which is still not expired since step 7. 

[0049] The above procedure is repeated until all data 
packets are transferred. A skilled person is aware that 
the timing of the reception of data in steps 4, 8 and 10 
depends on the behavior of the transmitter and the prop- 
erties of the link while the expiry of the timers is deter- 
mined In the receiver. Consequently, a reception of data 
packets can take place at any time during the procedure, 
e.g. step 4 can also occur simultaneously to steps 2 or 
3. There is also no mandatory relation between steps 8 
and 9 although the timers are preferably set to at least 
one round trip time. In an advantageous embodiment 
the first timer expires at the same time as the corre- 
sponding retransmissions are received. 
[0050] For the conditions triggering further status re- 
ports in steps 5 and 10 several options exist. In many 
cases, the transmitter requests a status report, e.g. by 
setting a poll bit in a PDU. A further option is to send 
status reports on a regular basis, for example after a 
predefined number of received protocol data units, in 
predefined intervals of time, either in measured in milli- 
seconds or number of transmission time intervals TTI. 
Alternatively or in addition status reports can be sent at 
the end of a predefined number of packets of a higher 
layer, i. e. at the end of SDUs which is advantageous as 
the further processing of an SOU can only be performed 
after completion. To allow an effective transmission of 
status reports it is proposed to send a status report when 
it fits in a defined number of protocol data units. If an 
estimated PDU counter (EPC) is used the trigger can 
also be the EPC expiry. Still further alternatives can be 
a defined number of defective protocol data units orthat 
a defined fraction of the receiver window or a buffer is 



filled . Combinations or simultaneous use of several con- 
ditions is possible. The alternative allowing the fastest 
retransmission is that a status report is sent as soon as 
a defective PDU is detected. In case of a high number 
5 of packet losses this requires however a large number 
of timers and status reports. 
[0051] The number of necessary timers corresponds 
to the number of status reports which are sent before 
the expiry of the first timer. Equivalent to a plurality of 

10 timers, a single timer can be used when each interval is 
released from protection at a specified corresponding 
threshold value of the single timer. In another preferable 
option forthe implementation, the timing unit comprises 
two timers denoted Interval timer and timeout timer in 

f s the following. The expiry value of the timeout timer cor- 
responds to the threshold after which a data packet can 
be requested in a status message for a second time. 
[0052] When a first status message is sent, both tim- 
ers are started with an indication that the timeout timer 

20 corresponds to the first status message. If a second sta- 
tus message is sent before the timeout timer is expired, 
the present value of the interval timer is stored with an 
indication of the second status message. The interval 
timer is reset and restarted. For any further status mes- 

25 sage which is sent before the timeout timer is expired, 
the present value of the Interval timer is again stored 
with an indication of the corresponding status message 
and the interval timer is again reset and restarted. 
[0053] When the threshold value is reached by the 

30 timeout timer, this indicates that the data packets indi- 
cated In the first status message can be requested again 
in a further status message if they are still defective. The 
timeout timer is attributed to the second status message 
and restarted with the threshold set to the value of the 

35 interval timer stored for the second status message, i. 
e. the timeout timer is set to expire after the stored in- 
terval timer value. When the threshold is reached, the 
same procedure is repeated for any further status mes- 
sage for which a value of the interval timer is stored. If 

40 the interval timer reaches the threshold of the timeout 
timer this indicates that any defective data packet can 
be requested in a status message. This implementation 
of the timing unit limits the number of timers required for 
the tracking of the status messages while ensuring a 

*> precise timing. 

[0054] Arecelveraccording tothe invention isdepict- 
ed in figure 4. Especially if the receiver is a user equip- 
ment it comprises hardware components like a display, 
a keyboard, a microphone and a loudspeaker which are 

so all omitted for clarity. The receiver has a processing sys- 
tem PS implementing the protocol stack of the commu- 
nication device and controlling the mentioned hardware 
components. The stack includes beside other layers a 
physical layer PL, an RLC layer and an application layer 

55 AL. Wireless signals are received or emitted via an an- 
tenna ANT and the signals are decoded and encoded 
for the wireless link WL in a transmission unit TM and a 
reception unit REC, respectively. A detection unit DU 
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detects defective data packets, e.g. by controlling 
checking bits included in the packets of the physical lay- 
er. The detection unit can for example discard defective 
packets. 

[0055] The processing system further comprises a s 
group of timers Tl., ... Tl„ and a memory MEM with sec- 
tions 1, ... n corresponding to the timers Tl and identify- 
ing the data packets in the receiver window which are 
protected by a specific timer Tl,. A control unit CT is 
adapted to perform the steps of the method as described « 
above. Especially, the control unit CT determines 
whether a status message S Is required. In this case, 
identifications of the defective packets are included in 
the status message unless the memory MEM indicates 
that the data packet was included in a previous status is 
message and the corresponding timer Tl, is not expired. 
The status message is then initiated by a communica- 
tion unit CU In the RLC layer and sent by the transmis- 
sion unit TM in the physical layer via the antenna ANT 
to the transmitter on the far end of the wireless link WL 20 
It is possible to implement the above units either as 
hardware or as software executed in the processing sys- 
tem PS of a device or as combination of hard- and soft- 
ware. 

[00563 If the proposed method is implemented with 25 
packet counters instead of timers there a different ad- 
vantageous options. In a first option, status messages 
are sent in periodic intervals of time SI corresponding to 
a number of f = RTT / SI status messages per round trip 
time RTT. Because of the regular status intervals, a so 
check whether the timing unit has reached a particular 
threshold needs not to be performed if the data packets 
for further status messages are suitably selected. For 
this purpose, a counter stores the number x,, of received 
PDUs between the preceding status message S n ., and 35 
S n for every status message S n . 
[0057] With VR(H) being the highest received se- 
quence number, the status message S n includes the de- 
fective data packets in the intervals [VR(H) - v VR(H)] 
and [VR(R); VR(H) - Sf = -„1 xjj. VR(R) Is the first un- « 
acknowledged data packet in the receiver window, i.e. 
the lower boundary of the receiver window. When a sta- 
tus message is requested by the transmitter, e.g. by set- 
ting a poll bit in a PDU, a status message Is only sent 
for defective packets in the interval [VR(R); VRfHJ-Xj' « 
= "o 1 x^ + x'J with x' n being the retransmitted PDU with 
the highest sequence number which was received since 
the last status message. The status request is stored 
and the remaining data packets for which the status was 
requested are included into the status message when so 
the corresponding threshold is reached. 
[0058] In a second option, a status message is sent 
by the receiver every Xq PDUs, i.e. the timing unit is a 
packet counter determining the sending of the status 
messages. The time between two status messages is ss 
ST = Xq / r, with r being the transmission rate of PDUs. 
r can for example be estimated, measured or read from 
configured parameters. A number of f = RTT / ST status 



messages is sent per round trip time RTT. If regular sta- 
tus intervals are assumed, a check whether the timing 
unit has reached a particular threshold needs not to be 
performed for a suitable selection of the data packets in 
further status messages. According to the invention, the 
status message in this case comprises the intervals fVR 
(H) - xo; VR(H)] and [VR(R); VR(H) - f XoJ. As in the first 
option , unnecessary retransmissions of packets with se- 
quence numbers near VR(R) are not excluded. This is, 
however, often advantageous as delays of these pack- 
ets are most critical. Alternatively, unnecessary retrans- 
missions can easily be avoided by selecting those inter- 
vals [VR(H) - Xo; VR(H)], [VR(H)-(f + 1 fa VR(H) - fxj, 
[VR(H) - (2f + 1 fa VR{H) - 2f xd ... for which the upper 
boundary is larger than VR(R). 
[0059] This embodiment is simple to implement but 
the efficiency depends on the assumption that the value 
of the packet counter corresponds to the elapsed time. 
Preferably, the value of f is therefore adapted as soon 
as changes in the transmission rate are identified to 
avoid unnecessary retransmissions or delayed status 
reports. To avoid a stalling of the algorithm, e.g. at the 
end of a transmission, it is possible to send always a 
complete status report for the receiver window upon a 
corresponding request of the transmitter or to send a 
complete status when no packets are received for a pe- 
riod of time which can for example be fixed or a function 
of f . In either option with a packet counter as timing unit, 
interval boundaries can be adapted by a correction val- 
ue in order to allow, e.g., for delays caused by retrans- 
missions or provide a safety margin. 
[0060] The above embodiments admirably achieve 
the objects of the invention. However, it will be appreci- 
ated that departures can be made by those skilled In the 
art without departing from the scope of the invention 
which is limited only by the claims. 



Claims 

1. Method for the transmission of data packets (D) 
from a transmitter (TR) to a receiver (RE), wherein 
defective data packets (D) are detected and a first 
status message (S, ) comprising an indication of de- 
fective data packets is sent from the receiver (RE) 
to the transmitter (TR) and a retransmission of de- 
fective data packets Is performed according to the 
first status message (S.,), characterized in that 
the receiver (RE) initializes a timing unit according 
to the sending of the first status message (S,), 
the receiver (RE) determines that a further status 
message (S 2 ) indicating defective data packets is 
required, 

defective data packets are selected for the further 
status message (S 2 ), wherein a defective data 
packet is selected if it is not indicated in the first sta- 
tus message (S,) or if the timing unit has reached 
a threshold, 
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indications of the selected data packets are includ- 
ed in the further status message (S2) and the re- 
ceiver sends the further status message (Sj). 

2. Method according to claim 1, wherein the timing unit 5 
is a timer {TI„ Tl 2 ) and the threshold is the expiry 

of the timer (TI„TI 2 ). 

3. Method according to claim 2, wherein the timer (Tl, , 
Tlj) comprises a threshold timer with the threshold 10 
and an interval timer, wherein the threshold timer 
and the interval timer are started according to the 
sending of the first status message (S,), wherein 
the value of the interval timer is stored when a sub- 
sequent status message (S) is sent and the interval is 
timer is reset and restarted and wherein the thresh- 
old timer is reset and restarted when it reaches the 
threshold and the threshold Is set to the stored value 

of the interval timer. 

20 

4. Method according to claim 1 , wherein the timing unit 
is a packet counter and wherein the threshold is a 
counter value. 

5. Method according to any preceding claim, wherein 25 
a further threshold corresponds to the further status 
message (S 2 ), the receiver (RE) determines that at 
least one third status message (S 3 ) is required and 
defective data packets (D) are selected for the third 
status message (S 3 ) and wherein an indication of a 30 
defective data packet is not selected for the third 
status message (S 3 ) if a check indicates that the 
packet is included in any preceding status message 
(S,, S z ) and the corresponding threshold is not 
reached. 35 

6. Method according to any preceding claim, wherein 
a status message (S) is triggered by at least one 
condition from a group comprising 

a reception of a polling request, 40 
a predefined number of received data packets (D), 
reaching of the threshold oradefined fraction of the 
threshold by the timing unit, 
the end or beginning of a data packet from a higher 
layer of a protocol stack, the size of a content of a « 
status message (S), 

a numberof data packets (D) detected as defective, 
and 

the reception of data packets (D) from a predeter- 
mined fraction of a receiver window (RW). so 

7. Method accord ing to any preceding claim, wherein 
the time between two subsequent status messages 
(S) is lowerthan a round trip time between the trans- 
mitter (TR) and the receiver (RE). 55 

8. Method according to any preceding claim, wherein 
data can be transmitted over channels with different 



properties and wherein at least one threshold is de- 
termined according to the properties of the channel 
used for data transfer. 

9. Method according to any preceding claim, wherein 
the receiver (RE) stores an information which data 
packets are identified In the status messages (S). 

10. Method according to claim 9, wherein the informa- 
tion identifies at least one boundary of an interval 
of sequence numbers, the interval comprising pack- 
ets (D) indicated in one of the status messages (S). 

11. Method according to any preceding claim, wherein 
the threshold corresponds to one round trip time. 

12. Method according to claim 11, wherein the thresh- 
old is adapted by a correction value for the round 
trip time. 

13. Method according to any preceding claim, wherein 
a status message (S) comprises indications of ail 
correctly received data packets. 

14. Method according to any preceding claim, wherein 
the data packets (D) are RLC protocol data units. 

15. Method according to any of the claims 1 to 13, 
wherein the data packets (D) are packets of a phys- 
ical layer (PL) in a protocol stack. 

1 6. Receiver for a communication system for the trans- 
mission of data packets (D), the receiver (RE) com- 
prising a unit (DU) for the detection of defective data 
packets and a communication unit (CU) to Initiate 
status messages (S)with an indication of defective 
data packets to a transmitter (TR) in the communi- 
cation system, characterized in that 

the receiver (RE) is provided with a timing unit and 
adapted to initialize the timing unit according to the 
initiation of a first status message (S.,), 
the receiver (RE) is provided with a control unit (CT) 
adapted to determine that a further status message 
(S z ) is required, 

the receiver (RE) is provided with a unit to select a 
defective data packet for indication in the further 
status message (S 2 ) if the data packet is not indi- 
cated in the first status message (S, ) or if the timing 
unit has not reached a threshold, 
the communication unit (CU) initiates the further 
status message (S 2 ) comprising indications of the 
selected data packets. 

17. Receiver according to claim 1 6, wherein the receiv- 
er is a radio base station, a user equipment (UE) or 
a radio network controller. 

18. Receiver according to claim 16 or 17, wherein the 
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receiver is adapted to perform a method according 
toanyoftheclaims1ta15. 

Program unit, said program unit comprising code for 
performing a method according to any of the claims s 
1 to 15. 
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